Foundry BigIron: Layer 3 Backbone Switch Family

01 /What BigIron was

BigIron was the modular backbone switch that Foundry Networks sold from the late 1990s. Where FastIron covered the wiring closet, BigIron took the core and distribution layers: a chassis with redundant management modules, hot-swappable line cards, and Layer 2 and Layer 3 forwarding in hardware. The Layer 2 versus Layer 3 page explains why this mattered at a time when routing in software was the bottleneck.

The name refers only to the Foundry product line. Two IronWare images existed for the chassis, a switch image and a router image, and the same hardware could run either. That split later carried over to the ServerIron and NetIron lines.

02 /Generations and architectures

03 /JetCore and what it changed

JetCore, announced in 2001, was the second Foundry ASIC generation. Its significance was that features previously handled by the management CPU moved into the forwarding path: access control lists, rate limiting, quality of service marking and sFlow sampling all ran at line rate on JetCore modules. Foundry was an early backer of sFlow, and JetCore hardware is one reason the protocol spread through university and ISP networks. Older IronCore modules coexisted in the same chassis but forwarded some features in software.

04 /BigIron figures that can be checked against a filing

Some figures can be stated because they appear in dated documents. Foundry's 10-K for 2001 describes the BigIron family as scaling to 232 Gigabit ports, 14 10 Gigabit ports or 672 10/100 ports in one chassis, forwarding up to 178 million packets per second, with redundant management modules and hot-swappable supplies and interface modules. The same filing dates JetCore to June 2001, calls it the third ASIC generation after IronCore I and II, notes a 0.18 micron process, sFlow and a packet sampling technique licensed from Hewlett-Packard, and backward compatibility with IronCore. The 10-K for 2003 names the BigIron MG8 and the NetIron 40G as the first two Terathon products.

For the RX the sources are the archived datasheet page of May 2005 and the 10-K for 2007: up to 64 10 Gigabit and 384 Gigabit ports per system, one million IPv4 routes in the routing table and 512 thousand in the forwarding table on each module, up to 40,000 access list entries; shipping from July 2005; IPv6 modules delivered in 2006.

05 /Chassis features

• Management redundancy: two management modules, one active and one standby, with configuration synchronised between them.
• Hot-swappable line cards: Fast Ethernet, Gigabit and later 10 Gigabit modules could be replaced without powering down the chassis.
• Layer 3 protocols: OSPF, BGP4, RIP, IS-IS on later releases, multicast routing, and VRRP and VSRP for gateway redundancy.
• Layer 2 features: VLANs, spanning tree variants, trunk groups and metro ring protocol on later images.

06 /Typical deployments

BigIron chassis were common in university cores, where price per Gigabit port and sFlow support counted, in regional ISPs as aggregation switches, and in high performance computing clusters as the Ethernet fabric before InfiniBand dominated. Several large web properties of the early 2000s ran BigIron in their data centers. The MG8 and RX generations were pitched at 10 Gigabit aggregation and at Internet exchange points.

07 /What replaced it

After the December 2008 acquisition, Brocade kept selling the BigIron RX for several years and issued IronWare updates for it, but positioned the NetIron MLX and later the MLXe as the core platform. The RX reached end of sale under Brocade around the middle of the 2010s; the exact dates depend on model and should be checked against archived Brocade notices. See the Brocade acquisition page for the corporate side.

08 /Running one today

A populated BigIron RX draws well over a kilowatt and sounds like a small server room. The smaller 4000 and RX-4 chassis are the only ones practical outside a rack with dedicated cooling. Firmware is no longer distributed and the last releases carry unpatched vulnerabilities in SSH, SNMP and the web interface, so isolate the management plane. For a lab the unit is still a fast Layer 3 backbone with real hardware ACLs and sFlow export, and its IronWare CLI transfers directly to later Brocade and Ruckus gear. Where BigIron sat between the closet switches and the provider routers is easiest to see from the full Foundry lineup.

09 /Checking a BigIron claim on the unit and in the record

The commands below, all from the IronWare reference, establish the image, the modules fitted and whether a router or switch image is running; compare the result with the Security Target list or a datasheet capture before trusting a listing. Record the capture date of any archived page you rely on, as described under how the archive handles Foundry manuals, and keep the chain from claim to source in the shape the evidence trail for network claims hub describes.

device# show version
device# show chassis
device# show module
device# show interfaces brief
device# show ip route
device# show log

• If show ip route is rejected, the switch image is loaded; the Layer 3 features listed above need the router image.
• show module reveals mixed IronCore and JetCore cards. A feature in hardware on one may be in software on the other, and the slower path wins for traffic crossing both.
• Samples need a collector; see sFlow export from the line cards.